A modern day printer is typically connected to multiple client devices (e.g., computers) through a network. The client devices have applications (e.g., word processing applications, spreadsheet applications, graphic art applications, etc.) and (typically) device drivers that enable the work product of the applications to be printed on the printer. The printing of such a work product on a printer typically involves the passing of a “job ticket” from the client device that generates the work product to the printer.
A job ticket is a high level description of the properties of the print out to be made. A job ticket typically defines the number of physical pages to be printed, whether the print out is to be single sided or double sided, the number of copies, the margins on the pages, the font size of the matter that is printed on the pages, the printer tray that the paper the work product is to be printed on is to be selected from, the paper bin that the finished printout is to be binned into and any post-processing procedures (e.g., collation, stapling, punching, folding, etc.). Many job tickets are written according to the Job Definition Format (JDF) standard published by CPI4 (the International Cooperation for the Integration of Processes in Prepress, Press and PostPress Organization). The JDF specification provides for the definition of parameters like those just mentioned above in an XML format.
Modern day printers also include one or more processers and associated memory to store and execute program code locally on the printer. Much of this software is used to control the internal operations of the printer. One such control operation is to expand the job ticket into a “print job”. A print job is a “sheet-by-sheet” specification of the matter to be printed. A sheet includes a corpus of information used by the printer to print a physical piece of paper according to the job ticket. There is typically one sheet per physical piece of paper that is printed irrespective of whether the piece of paper is printed single sided (“a page per sheet”) or double-sided (“two pages per sheet”).
Thus whereas a JDF job ticket describes the print out more generally, the “print-job” is akin to a collection of data sheets that is created to separately define the characteristics of each of the printed pieces of paper of the document.
For example, if a first chapter of a document is to be printed on yellow paper in 12 point font and a second chapter of a document is to be printed on blue paper in 14 point font, the JDF job ticket might specify the range of the first chapter and that the pages within this range are to be printed from the tray having yellow paper in 12 point font as well as the range of the second chapter and that the pages within this range are to be printed from the tray having blue paper in 14 point font.
When the printer receives the JDF job ticket it essentially forms the print job by creating a separate sheet for every piece of paper to be printed out and storing these sheets in memory. Thus, there will be stored in memory separate sheets for every page of the first chapter and separate sheets for every page of the second chapter. While the printer is in the act of printing the document, it refers to the sheets (e.g., in sequence) to understand the properties that the corresponding physical pieces of paper are to be printed.
A feature of prior art document printing concerns the use of an “input profile”, a “printer profile” and “profile connection space” (PCS). Consider an example were a user wants to print a picture taken with a digital camera. After the picture is taken with the camera, the digital image from the camera is processed with an input profile for the camera. The input profile may characterize various imperfections in the camera such as “true red” being recorded by the camera as something more like “orange-red”. As such, the input profile for the camera is used to convert the “orange-red” components of the digital image into “true red” in PCS. That it, PCS attempts to describe the picture as if it were taken by a perfect camera.
In order to print the picture, the PCS version of the image is processed by an output profile for the printer. Here, the printer can have imperfections similar to the camera. For example, the printer may print “true-red” that is viewed by the human eye as something more like “yellow-red” when printed on a particular type of paper and viewed under a certain view condition (a view condition basically describes the conditions under which the printed image will be viewed (e.g., in a room lit with a light bulb, outdoors in sunlight, etc.)). Similar to the input profile, a printer profile is used to convert the image from PCS space into final color values, e.g., CMYK color information that is properly adjusted to print something closer to actual red.
The printer profile for this example specifies the specific pixel values that correspond to “true red” as well as the pixel values for the “new” color that are to be printed in place of true red to correct for the deficiency of the printer (e.g., pixel values for a shade of “pink-red”). The description for this particular printer profile therefore includes: 1) the new pixel values to be switched in (e.g., “pink-red”); 2) the pixel values to be switched out (e.g., “true-red”); 3) the condition that triggers the substitution effect (e.g., the particular type of paper and view condition that causes “true-red” to be printed as “yellow-red”). Typically, a printer profile specifies more operations than just a single color change as described in the simple example above.
As large printer systems are complex, it is not uncommon for a user to desire a change to be made to a printer profile. For example, a user may recognize a situation where the printer profile itself does not accurately print all the colors it is intended to print. In this case, the user applies a “substitution” to the printer profile. Continuing with the above example where the printer profile changed an input color of “true red” from PCS space to output color of “pink-red”, a user may recognize a situation where this particular change of colors is not appropriate (e.g., because the printer presently has another imperfection that the current printer profile does not fully address). As such, the user may now desire that the printer attempt to print “purple-red” for input pixel values specified as “true red” from PCS space.
As such, the user specifies a “color substitution” to the printer profile that indicates “true-red” from PCS space is to be printed as “purple-red” rather than “pink-red” (the later being what the profile specifies should be printed). The implementation of the substitution can be viewed as intercepting the “true-red” color from PCS, by-passing the printer profile for the “true-red” color and instead specifying “purple-red” directly from the substitution.
A single printer can possess a number of different profiles that can be used for any particular job. According to one approach, “color management space” is a user environment in which a user selects printer profiles to be used (e.g., for a specific job, over for the life of the printer, etc.). A problem, however, is that no convenient, organized way of presenting the corpus of various substitutions that may be made to these profiles currently exists.